This invention relates to computer programming, and more particularly to a method of making callable symbols visible outside a code image in an environment supporting sharable images.
When a computer program is compiled to produce an object code module, there are symbols within this module that should be visible outside the module, as in procedure calls or the like. Usually, a number of these modules are linked together to produce an executable image, and at the time of linking the relative locations of the callable symbols are identified. When the combined image is activated (at run time) on a central processing unit (CPU), the symbols are assigned memory addresses, so calls are made to specific addresses. Most operating systems used on computers create a single, combined executable image at run time, so these assigned memory locations bear a fixed relationship to other parts of program.
A feature of the VAX/VMS.TM. operating system, however, is the support of sharable object code images. An applications program may make use of library images, e.g., for printing, video display, etc., that are used by many other programs. Rather than use a copy of each of such library images for each applications program, there is provided the capability of sharing such images by a number of programs activated at the same time in a multi-user and/or multi-tasking environment. Thus, when several programs make use of a library image, only one copy of this image need be activated, instead of a copy for each program using it. In this manner, real memory space is conserved. More importantly, in a hierarchical memory it is more likely that the shared image will stay in higher-speed memory rather and be accessible when needed, so overall performance (speed of execution) is improved. That is, it is more likely that the code image needed will be in cache, or in real memory instead of swapped out to disk in a virtual memory system, when it is needed.
Using this sharable image feature of the VMS operating system, large program units ("images") may be constructed from a set of compiled modules, and may invoke service in other such images and in the operating system itself. Hence, images serve as super modular program units which may be supplied by different vendors and which, with certain limitations, do not need to be rebuilt if others around them change. A main program block may use images in memory for specific purposes (e.g., math processing, windowing, etc.) used by other tasks executing on the same CPU, in a multiuser, multitasking environment. In this manner, these auxiliary program functions need not be duplicated in memory, thus conserving memory space, and time is saved upon image activation.
While the feature of sharable code images has been a valuable part of the VAX/VMS operating system, the advance of computer architectures has made it necessary to provide improved or expanded capabilities for programs taking advantage of these advanced architectures. For example, data path widths have expanded from 8-bit, to 16-bit, to 32-bit, and now to 64-bit. Memory has become vastly cheaper and faster. Semiconductor VLSI technologies have allowed more and more of the component parts of a computer to be integrated, with resultant improvements in speed, cost, power dissipation and size. Advances in compiler theories have made it advantageous to expose more of the elemental steps of execution of functions to the programmer or compiler rather than embedding them in microcode. These and other factors have resulted in a trend toward so-called Reduced Instruction Set Computer (RISC) architectures rather than the Complex Instruction Set Computer (CISC) architecture of the VAX machine. In particular, an advanced 64-bit RISC architecture taking advantage of all of these technology improvements has been developed as set forth in pending U.S. patent application Ser. No. 547,619, filed Jun. 29, 1990, now abandoned, assigned to Digital Equipment Corporation, providing a high-performance vehicle for which programs written in VAX code may be transformed. In order for applications programs written for the VAX architecture and the VMS operation system to be directly transformed, many features of VAX/VMS should be supported in the operating system for the advanced RISC architecture. Among these is the concept of sharable images.
Since the advanced RISC architecture has a different instruction set and different linkage mechanisms, provision must be made for translating code from VAX/VMS so that the feature can still be implemented. Additionally, the sharable image feature in VMS had limitations with regard to independence of images, and by relaxing these limitations the implementation in the advanced RISC environment is made more flexible and less constrained.
Previously, the VAX/VMS operating system supported sharable images by employing a transfer vector in the target image. This transfer vector was a data structure having an entry for each procedure within the code image that was to be visible externally. Each entry contained the offset to one of the procedures, and the entries were in a fixed order. The calling image need only have the address of the transfer vector and the order number of the called procedure within the transfer vector. So, at image execution time, the called procedure is referenced by merely referencing the transfer vector (or, more precisely, an offset in the vector according to which ordered number this called procedure was placed) where a pointer to the actual address is found. The actual location of the procedures Proc.sub.-- A, Proc.sub.-- B, etc., in the image 11 could vary, with updates or corrections to the code, for example. As discussed above, however, this method has certain shortcomings in the present environment.
Thus, VAX/VMS by the sharable image feature provides a limited kind of linking between images at program startup. This linkage requires that programmers manually construct a "transfer vector" within each image to be shared, where each entry represents the transfer point for a procedure within that image or possibly a data cell or structure. By constructing this vector (a typical practice at many interfaces of an operating or programming system), the relative value (offset) of each entry is made invariant and may be bound into other images which call this one, so long as the location of the transfer vector is known at activation time.
There are several disadvantages in the use of transfer vectors in the sharable image feature, however. First, additional execution overhead is imposed upon each call to a shared image because of having to pass control through the transfer vector and then to the actual target routine. This overhead consists of executing added instructions and making additional memory references. Secondly, additional programming effort is needed to specify and maintain the transfer vector. Third, execution errors occur if the vector is inadvertently changed. Fourth, there is a lack of flexibility in referencing data cells and structures (as distinguished from executable procedures), since they must be located within the transfer vector itself, or else incur additional execution overhead and programming effort. Fifth, special language semantics may be required for the specification of transfer vectors which may not be available in the programmer's language of choice.